Data networks contain various network devices, such as switches, that act as logical ports for sending and receiving data between two locations. For example, a frame relay cloud contains many interconnected switches that allow data packets to be channeled through the cloud to a remote destination. A virtual connection is established between a host and the remote destination by channeling the data packets through the network. In the frame relay example, the virtual connections through the frame relay cloud are permanent because the end devices do not select different routes for data packets sent between the host and the remote location, but always send the data packets through the same path. A host may have many of these permanent virtual circuits (PVC) linked to many remote locations. The switch that acts as the node of entry into the cloud for a PVC is connected to the host through a physical circuit, such as a T1 line.
The network devices are generally in communication with one or more network management servers that orchestrate the operations of the network. In the frame relay example, a network management server communicates with a switch to instruct the switch to function as a logical port (LPort) of the frame relay cloud. The switches of the network cloud send data packets to particular destinations designated in the data packet headers and thereby create PVCs in response to the information provided by the management server. Because the network management server has access to the switch, it can log the operating parameters of the switch.
To properly maintain the network and the flow of data through it, it is necessary for technicians to monitor the operation of the network devices that form the network. Technicians access LPort information through terminals that communicate with the network management server typically through a local area network (LAN). Conventionally, the terminals display a map-based graphical user interface (GUI), such as the NavisCore™ system by Lucent Technologies, that is received from the management server. The map-based system requires the user to navigate through several map and configuration displays to find the appropriate switch prior to accessing its LPort information.
For each display presented while finding the appropriate switch, a fetch to the management server is required. Once the proper switch has been found, accessing operating statistics requires one or more additional fetches to the management server. Viewing the virtual connections of the LPort, their status and/or statistics requires additional GUI navigation and fetches. Other information used by the technician, such as trap logs indicating LPort or virtual connection failures, any permanent virtual circuits built to the LPort, or the far-end physical connection, requires additional fetches across the LAN.
When hundreds of technicians attempt to monitor several LPorts each, the numerous fetches to the management server at any given time result in the LAN becoming overworked and congested. The time becomes too lengthy for each sequential screen to be displayed when searching for the LPort and its information through the map driven GUI. Furthermore, when one user has already locked an LPort through the management server so as to have access for its LPort information, the conventional map driven GUI provides only a generic identifier of the user even though the technician must contact the user to request that he or she unlock the LPort. Determining the user's identity and contact information also may involve additional time-consuming fetches.
Therefore, there is a need for a system that allows a user to access information about an LPort without requiring many fetches to the management server.